Thanks for the pull request, @xitij2000! I've created OSPR-2387 to keep track of it in JIRA. JIRA is a place for product owners to prioritize feature reviews by the engineering development teams.

Feel free to add as much of the following information to the ticket:

• supporting documentation
• edx-code email threads
• timeline information ("this must be merged by XX date", and why that is)
• partner information ("this is a course on edx.org")
• any other information that can help Product understand the context for the PR

All technical communication about the code itself will still be done via the GitHub pull request interface. As a reminder, our process documentation is here.

If you like, you can add yourself to the AUTHORS file for this repo, though that isn't required. Please see the CONTRIBUTING file for more information.

Your PR has finished running tests.

@edx/learner-product Could you take a look at this proposal?

Thanks for your help @mduboseedx -- could we maybe get an estimate on when someone will have time to look at this?

@sstack22 @shamck @katymyw Could this proposal be given a review?

@xitij2000 Just a quick update, I had actually pinged the wrong folks above, but have now reached the correct ones through Jira. When I'm back into the office on Monday, I should have a better update for you.

@mduboseedx Thanks!

Thanks for the proposal on this! This seems like a reasonable approach, a few items / questions that might be easier to address with screenshots or once you have a working proof of concept.

Settings / Options
Thinking through potential combinations of settings and override concerns for authors I might suggest a minor change to what you suggested above.

Course Visibility Default Setting: Public, Preview Only, Private
Public: Course outline and all units are available by default publicly, unless a subsection or unit is forced to be private.
Preview Only: Only the course outline is available publicly but content pages are locked / gated with a message explaining that users must log in to access the content.
Private: Our current default, but anybody who attempts to access specific content pages is redirected to the course home page (current behavior.)

Subsection / Unit Level Visibility Override
Allow Public Access: Force this level (and any children) to be public and visible to anonymous users. Show this control in cases where a subsection or unit isn't already marked as public by a higher level course structure or course level setting.

Blocked / Gated Access Message
When learners attempt to access a gated view, rather than show a popup we could show an entire page level message / area, replacing the content from that view / page. We would need a variant for this if certain pages (ex: anything in a special exam area) were accessed, even if the course was marked as public. (We currently redirect to the home page with a message, we could keep doing that as well.)

Special Exam
Just a special call out here but I think we should always force special exams (timed / proctored subsections) to be gated / inaccessible even if the rest of the course is marked publicly available

Preview Only Mode Messaging
When learners are anonymously accessing a course content view, we can make a page level variant of the current message to log in / register that exists. This could let people know they can create an account to access the full course and streamline enrollment post registration / login to get back to this screen.

@nasthagiri This is the OSPR we briefly discussed under product review. Suggestions welcome.

@marcotuts Thanks for all the great feedback!

@marcotuts I have a few doubts about the above suggestion though.

• How would a subsection/unit be forced to be private? Currently private is the default. Does this mean there needs to be another visibility option to force a unit to be private, or did you just mean to say that content like special exams (and possibly other blocks) are always private?
• I don't think I fully understand the difference between blocked/gated view and preview only mode messaging. By blocked/gated view do you just mean private units in a public view or do you mean unreleased content/content with a prerequisite?

Notes inline below:

How would a subsection/unit be forced to be private? Currently private is the default. Does this mean there needs to be another visibility option to force a unit to be private, or did you just mean to say that content like special exams (and possibly other blocks) are always private?

Out of the box we would have courses with:

• Course Visibility Default Setting: Private (existing behavior, would be a new 'setting' with this work)
• No Subsection / Unit Level Visibility Override to start
  -- Course teams could technically add these to specific parts of their course if they wanted even if the overall course is private. This would let you set a few pages as 'landing pages' for potential learner discovery even if the rest of the course was closed.
• Accessing content pages directly would redirect you to the home page (current behavior)
• Special exams wouldn't be visible / accessible (current behavior)

Course team sets visibility to Preview Only:

• Course Visibility Default Setting: Preview Only (new option with this work)
• No Subsection / Unit Level Visibility Override to start
  -- You could still use this setting to force subsections to be public
• Accessing content pages directly would NOT redirect you to the home page
  -- Message is shown above content area letting people know they can create account / login to access full course (new behavior with this work)
• Special exams wouldn't be visible / accessible (current behavior)

Course team sets visibility to Public:

• Course Visibility Default Setting: Public (new option with this work)
• No Subsection / Unit Level Visibility Overrides to start
  -- You could still use this setting to force subsections to be private
• Accessing content pages directly would NOT redirect you to the home page
  -- Message is shown above content area letting people know they can create account / login to access full course (new behavior with this work)
• Special exams would STILL not be visible / accessible (current behavior)

I don't think I fully understand the difference between blocked/gated view and preview only mode messaging. By blocked/gated view do you just mean private units in a public view or do you mean unreleased content/content with a prerequisite?

I could maybe generate a mockup for this to help communicate what I'm talking about here.
Option 1: If learners attempt to access a private / blocked view we could keep current behavior of redirecting you to the course home?
Option 2: Let them access the url for that blocked view, but override the content and show a message saying this part of the course is locked / not available anonymously?

(I think option 1 makes the most sense, since it exposes no visibility of whether or not a private content url exists?)

@marcotuts Thanks for that clarification. I think I understand what you're going for now.

So we'll have a new visibility override options for Units and subsections that lets you set them to Public/Private/None, where None is the default and will just inherit the global visibility for that course.

In a private course with a public unit/subsection, you'd be able to share a link to that unit/subsection and people could see it without logging in. Likewise, in a public course with private content, it would only show up for users that are logged in.

If linked to a private area in a private course the user will be redirected to the homepage. If linked to a private area in a public/protected course, you'll see a message asking you to log in/register (or alternatively redirect to homepage to be consistent with the current behaviour). I would vote for the former behaviour since it gives users clear a message that they need to log in. A middle-path would be to redirect to a new page that recommends that users sign in, or allow this to be customised to a marketing page.

@marcotuts Also in Preview mode, you say:

-- You could still use this setting to force subsections to be private

I assume in that case you mean "You could use this setting to force a subsection to be public"?

@xitij2000: Where would user scoped XBlock field state be stored when an anonymous user is interacting with course content?

@ormsbee The idea is to start with support for only a limited set of static content, like videos and HTML, which could advertise that they support anonymous access. In the case of anonymous access, the state will simply be discarded for now. It's just to allow a read-only view of course content.

Following up on @ormsbee's note - I wonder if CAPA problems would need to be updated to know when they are in anonymous mode and be able to limit interactivity at the xblock level. "You can interact with this problem once you have logged in and enrolled." (If we did this kind of awareness for "read only" mode for CAPA it would also be helpful for offline mobile capa webviews!)

Some uncollected thoughts:

Per-XBlock handling

@marcotuts: We might want to make a new XBlock view method that is anonymous_view as a way for the XBlock itself to flag whether it supports being used in an anonymous context. XBlocks with trivial requirements could alias that to student_view. That way capa can take whatever steps it needs but blocks for which the conversion is trivial can just alias it to the student_view.

Analytics

Do we capture events still? Hash of the session as a user identifier of sorts?

Overall Complexity

Access control is a little crazy at this point. We have six VisibilityState values that are derived purely from content: live, ready, unscheduled, needs_attention, staff_only, gated. We have the user partitioning schemes for cohorts, enrollment tracks, and randomized content. We have the whole gating API for prereqs. We have inherited values. We have the silly hide_from_toc attribute. We have beta users.

I wasn't initially sold on the overall approach proposed here, but I've warmed up to it and how it balances functionality and scope of changes. I had favored a long term approach of using the cache for maintaining student-backed session state and hiding the difference from XBlocks. But the more I think on it, the more the complexities of that don't seem worthwhile. If the product goal is to give a flavor of the course, it's easier to just admit up front that certain things won't work, and let XBlocks worry about their own special cases (e.g. ORA2, SGA).

So along the lines of containing complexity, I'd like to understand:

1. How much of what's proposed can be implemented using what we already have (e.g. Gating API, cohorts)?
2. Are there any ways we can reduce the number of possible permutations of this? For instance, do we need to be able to toggle this at the Unit level at all? Can we just limit it to the Sequence level (even if it's inherited down under the covers)?

FYI: @cpennington, @mulby

@ormsbee We were going for preview_view internally for this but perhaps anonymous_view is clearer. We also looked into the approach of storing data in local/sessionstorage but felt it would give a false impression. There are blocks (like problem builder) that have their own Django models, or other ways that interact with user data that are hard to predict, so it's better to have them explicitly buy into this feature.

Just to indicate our roadmap we have:

• https://github.com/edx/edx-platform/pull/18344 [reviewed]
• https://github.com/edx/edx-platform/pull/18537 [ready for edX review]
• Add support for preview_view/anonymous_view and implement it for html
• Implement preview_view for videos
• Add unit/subsection visibility options
• Indicate visibility on the frontend

Some stuff may get shuffled around or broken down further / combined but that's roughly it. Unit-level visibility is quite important for the client sponsoring this work. We could simplify that by only having that option for units, and if a subsection has a single unit that's public, then that subsection will be public in the outline.

As for using cohorts or gating to implement this, since those are currently for enrolled users only, I don't know how that would work, I'm not familiar enough with them yet. We can look into that, though.

Hello @ormsbee

After researching the cohorting + content groups features, we believe that could provide the bulk of the requirements for granular anonymous course access.

By defining a course public, which makes the outline, units and xblocks visible to anonymous users, specific units can be added to a content group associated with enrolled learners to make those only available to enrolled learners.

One feature that we would need to implement is a new cohort strategy for "unenrolled users" to mark content visible only to anonymous users. This would be used to place content such as upsell messages calling unenrolled users to enroll. This would be achieved by placing such content in a specific content group associated with that cohort.

CC. @symbolist @xitij2000

Hi @ormsbee, following up on the conversation in the Slack Architecture room, here are the answers to your questions.

@marcotuts This takes care of the two sets of behaviors you described under "Out of the box we would have courses with:" and "Course team sets visibility to Public:" in your comment above (with small differences).

For the behavior described under "Course team sets visibility to Preview Only:" i.e. Units are private by default but can be forced to be public, we are open to suggestions (maybe a "default" Content Group?). Since it is achievable with the method described below with a bit more work (i.e. marking all the other Units with Content Groups), it would also be fine to add this UI optimization in a later iteration.

XBlock Views

We agree on implementing a new view for XBlocks. This view should assume that no learner data is available and show a preview of the content. For example, XBlocks like html and video can show all their content (or maybe even have configuration options like only show first 30 seconds of the video) but CAPA can show a view where the problems are disabled; it is up to the XBlock how much should be revealed. There is going to be a default implementation of this view so that if any XBlock does not implement it, in its place a "Please login and enroll to view" placeholder message will show.

Outline & Courseware Visibility

Course Authors can switch between these three options at any time and the changes take effect immediately:

2.1. By default all courses will work like they do now.
2.2. If only the Outline should be visible to anonymous and non-enrolled learners, Course Visibility is set to preview.
2.3. If the Outline and some or all course content should also be visible to anonymous and non-enrolled learners, Course Visibility should be set to public. The XBlocks preview_view will be used for these visitors instead of the student_view.

Which XBlocks show in Outline and Courseware

Which XBlocks will show in the Outline for cases 2.2 and 2.3 and for Courseware in case 2.3 can be controlled by Content Groups+Cohorts:

3.1. By default, if a course does not have Content Groups+Cohorts enabled, all XBlocks will show in the Outline and Courseware for anonymous and non-enrolled learners.
3.2 If some XBlocks are marked with a Content Group, just like it is the case currently, they will only be visible to learners in the corresponding Cohort (which are obviously going to be enrolled learners).
3.3. We can add a new Cohort Assignment Method "Non-enrolled Learners" (feel free to suggest a better name). Only one Cohort with this assignment method can be created. If it is present anonymous and non-enrolled learners will be considered to belong to this Cohort. So only they will see XBlocks marked with the corresponding Content Group.

Advantages of this mechanism:

• Course authors do not have to learn yet another permission method or try to figure out how to make it work along with Cohorts or Enrollment Tracks.
• No new Studio UI or Instructor Dashboard UI is needed (except for the simple Course Visibility setting and Cohort Assignment Method option).
• Since this relies on the existing Partitions logic, very minor changes are needed to the XBlock level permission checks.
• This can work with Enrollment Tracks too (since both are built on top of Partitions); there just needs to be an additional track "Non-enrolled Learners" or "Preview Track" which is assigned to anonymous and non-enrolled learners.

For now, we are planning to keep this behind a course waffle flag. It can be removed whenever appropriate.